Operation Not Permitted when on root - El Capitan (rootless disabled) [closed]

Question

I am trying to move something to /usr/bin on OS X El Capitan. I have disabled rootless using the following commands: sudo nvram boot-args="rootless=0"; sudo reboot, but I keep getting the same error:

MacBook-Air:~ Mark$ sudo cp class-dump /usr/bin
Password:
cp: /usr/bin/class-dump: Operation not permitted
MacBook-Air:~ Mark$ sudo mv class-dump /usr/bin
mv: rename class-dump to /usr/bin/class-dump: Operation not permitted

Harkness

Why are you trying to put class-dump in /usr/bin? Local additions belong in /usr/local/bin, and rootless allows you to put things there... – Eschalot

Just make an alias in ~/.bash_profile and don't frack with /usr/bin – Parceling

class-dump is directly used for programming (reverse engineering tool - directly for programming), so the reason of closing doesn't sound valid. Besides, 28 stars, almost 40 question upvotes and 90 answer upvotes means the question is useful. – Gentry

reverse engineering because it is used for getting a list of classes? – Breezeway

Related: apple.stackexchange.com/questions/339862/… – Dugong

Answer 1

Nvm. For anyone else having this problem you need to reboot your mac and press ⌘+R when booting up. Then go into Utilities > Terminal and type the following commands:

csrutil disable
reboot 

This is a result of System Integrity Protection. More info here.

EDIT

If you know what you are doing and are used to running Linux, you should use the above solution as many of the SIP restrictions are a complete pain in the ass.

However, if you are a tinkerer/noob/"poweruser" and don't know what you are doing, this can be very dangerous and you are better off using the answer below.

Harkness

@Chris, You'll need to reboot with CMD+R again, open the terminal and run csrutil enable; reboot. The command does not work in the normal mode unfortunately. – Kaon

@AlexanderKachkaev Yep, that's what I did. I just wanted to point out that everbody should enable it again after performing the changes! Otherwise the system integrity protection is permanently disabled which can lead to serious problems. – Poltroonery

It will only lead to serious problems if you remove/modify something you shouldn't be removing/modifying. In other words, if you know what you're doing, it is perfectly safe to leave it disabled. – Quintus

@Quintus if you leave it disabled, you are less safe. Aren't you exposed to a malicious code modifying your system ? – Poltroonery

@Poltroonery it doesn't make sense to handcuff yourself to your office chair to avoid being hit by a car... in other words... if you know to look both ways before you cross the street... it's perfectly safe not to handcuff yourself to a chair – Quintus

@Quintus This is like saying you can use the root user all the time because you will only screw up your system if you dont know what you are doing – Duty

@Duty It's not like that at all. You still have to enter your password when you sudo. It's also been this way for 30 years… if you know what you're doing… it's perfectly safe. – Quintus

@Quintus Here is a scenario. I use port to install packages, using sudo. Sometimes a multitude of sub-packages are installed automatically. Of course they are MD5 or SHA1 signed, but are you 100% confident that none of these packages contain malicious code (or installation errors that could mess up the /usr system). Maybe I am paranoid. – Poltroonery

Annoyingly, I've had to re-enable this occasionally after some software updates. Status can be checked via csrutil status. – Rubbish

csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS. – Cherenkov

On macOS monterrey, I get this error: zsh: command not found: crsutil – Squeeze

Answer 2

Correct solution is to copy or install to /usr/local/bin not /usr/bin.This is due to System Integrity Protection (SIP). SIP makes /usr/bin read-only but leaves /usr/local as read-write.

SIP should not be disabled as stated in the answer above because it adds another layer of protection against malware gaining root access. Here is a complete explanation of what SIP does and why it is useful.

As suggested in this answer one should not disable SIP (rootless mode) "It is not recommended to disable rootless mode! The best practice is to install custom stuff to "/usr/local" only."

Zephyrus

This didn't quite do the trick for me - I had some luck aliasing (for instance, in my case) java to /usr/local/bin/java in my bashrc aliases, after I made the appropriate link in that folder as this answer suggests. – Costplus

So, does this leave no way to rm anything in /usr/bin/? I understand SIP has its purpose, but want to remove one specific executable. – Linville

I do have /usr/local/bin in my path and openssl 1.0.2n is correctly symlinked to /usr/local/bin/openssl but every time I do which openssl it still shows the /usr/bin/openssl which is the older OpenSSL 0.9.8zh 14 Jan 2016 version. How do I get my system to prefer the /usr/local/bin/openssl one over the other one? – Gasbag

Answer 3

If you want to take control of /usr/bin/

You will need to reboot your system:

Right after the boot sound, Hold down Command-R to boot into the Recovery System

Click the Utilities menu and select Terminal

Type csrutil disable and press return

Click the  menu and select Restart

Once you have committed your changes, make sure to re-enable SIP! It does a lot to protect your system. (Same steps as above except type: csrutil enable)

Strasser

Answer 4

Most probable reason is the system integrity protection (SIP) - csrutil is the command line utility. You need to disable it to view the directory.

• To view your status you need to:

csrutil status

• To disable it (which is usually a bad idea):

csrutil disable

(then you will probably need to reboot).

To enable it (which should be turned back on when you are done):

csrutil enable

Arapaima

Answer 5

You just need to allow Terminal app to perform such modifications.

I've tried the following and it worked like a charm 😇: Pull down the  Apple menu and choose ‘System Preferences’

Choose “Security & Privacy” control panel

Now select the “Privacy” tab, then from the left-side menu select “Full Disk Access”

Click the lock icon in the lower left corner of the preference panel and authenticate with an admin level login

Now click the [+] plus button to add Terminal application with full disk access,(App to fetch from Application folder).

Utta

This doesn't work for /usr/bin, just tried it myself. – Remount

/usr/local/bin works for me – Harald

When answering a question, you should consider the actual directory, not the fact that you are getting the same error with a different directory. While 'Full Disk Access' does work for some directories, e.g. ".Trash", for others (like /usr/bin, the actual directory) you need to disable System Integrity Protection. So please, before you answer, read along the fine print. – Nevermore